home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1996 November: Technology Seed / Mac Tech Seed Nov '96 / Mac Tech Seed Nov '96.toast / mac / QuickTime MPEG a6 / YCrCb Codec Dev Doc < prev   
Encoding:
Text File  |  1996-11-01  |  9.9 KB  |  193 lines  |  [ttro/ttxt]
  1. YCrCb Codec Info.
  2.  
  3. The MPEG decoder engine produces planar Y'CrCb data in a single block of data that 
  4. is passed on to the ICM for display.
  5. Some basic properties of this block of data are specified in the ImageDescription
  6. created for the picture (or sequence of pictures) and this data can be accessed 
  7. from ICM in the usual fashion. Such information includes the width and height of 
  8. the Y'CrCb data, and the length of this block of data representing the image.
  9.  
  10. The block of data itself is in the form of a YCrCbVideoFrame struct, defined as
  11.  
  12.     struct YCrCbVideoFrame
  13.     {
  14.         //These are publicly defined fields.
  15.         UInt32 headerSize;
  16.         UInt16 luminanceOffset, cbOffset, crOffset;
  17.         UInt16 luminanceRowBytes, chromaRowBytes;
  18.     
  19.         //Following, here, is the actual Y, cR and cB data.
  20.     };
  21.     typedef struct YCrCbVideoFrame YCrCbVideoFrame;
  22.     #define kYCrCb420Type 'mpyc'
  23.  
  24. The headerSize is right now set to sizeof(YCrCbVideoFrame)==14 bytes.
  25. Conceivably that could change in the future.
  26.  
  27. The more interesting information is the luminanceOffset, cbOffset, and crOffset
  28. fields. The luminance, cB and cR data is stored as three planes of data, 
  29. specified by a ptr in memory and a rowbytes, just like a pixmap. 
  30. The height of the luminance data is given by the height passed on to ICM.
  31. The height of the cR and cB data is half that. (Note that the height passed on
  32. to ICM will be, per the MPEG specs, a multiple of 16, ie a multiple of a 
  33. macroblock height. Likewise the width will be as multiple of 16.)
  34. One might imagine that the rowBytes information is redundant, that it would 
  35. simply equal the width of the picture. This is not true for two reasons. The 
  36. first is that the widths of rows are padded by some number of bytes to stride 
  37. different rows starting at different offsets in a cache line and thus making
  38. the MPEG engine faster. The second is that the luminance and chroma data 
  39. are interleaved with each other (in a fashion that will not be described further 
  40. because it may change).
  41.  
  42. So in one's routine for actually displaying this data one will use code that 
  43. looks something like 
  44.  
  45. pascal ComponentResult YCrCbDisplayFrame(SomeStruct* myVariousStuffStruct, 
  46.   YCrCbVideoFrame* framePtr)
  47. {
  48.     UInt8* luminancePtr;
  49.     UInt8* cRPtr;
  50.     UInt8* cBPtr;
  51.  
  52.     luminancePtr=((UInt8*)ycrcbVideoFrame) +ycrcbVideoFrame->luminanceOffset;
  53.     cRPtr       =((UInt8*)ycrcbVideoFrame) +ycrcbVideoFrame->crOffset;
  54.     cBPtr       =((UInt8*)ycrcbVideoFrame) +ycrcbVideoFrame->cbOffset;
  55.     
  56.     /*
  57.     Now run over these arrays, with loops that look like    
  58.     for(h=0; h<myVariousStuffStruct->srcHeight; h+=2){
  59.         for(w=0; w<myVariousStuffStruct->srcWidth; w+=2){
  60.             cr =*cRPtr++;
  61.             cb =*cBPtr++;
  62.             y00=luminancePtr[0];
  63.             y01=luminancePtr[1];
  64.             y10=(luminancePtr+ framePtr->luminanceRowBytes)[0];
  65.             y11=(luminancePtr+ framePtr->luminanceRowBytes)[1];
  66.             luminancePtr+=2;
  67.             //Do some stuff with y, cr, cb to get them to the screen.
  68.         }
  69.         cRPtr+=       ( framePtr->chromaRowBytes - myVariousStuffStruct->srcWidth/2 );
  70.         cBPtr+=       ( framePtr->chromaRowBytes - myVariousStuffStruct->srcWidth/2 );
  71.         luminancePtr+=( framePtr->luminanceRowBytes*2 - myVariousStuffStruct->srcWidth );
  72.     }
  73. }
  74.  
  75. Now a few notes.
  76.  
  77. The type of this codec is 'mpyc'.
  78.  
  79. I have stuck to the exact terminology of Y'CrCb, although in colloquial speech one tends 
  80. to use YUV as easier to pronounce. Y'CrCb is precisely define in CCIR recommendation 601
  81. (now renamed ITU-R BT 601). If you are unfamiliar with details of this, I would recommend 
  82. reading details of it. The easiest way to find such details is to use any web search engine
  83. with the keywords CCIR 601 and read two or three of the documents that result. 
  84. Many of these documents (for example the ColorSpaces FAQ) describe in great detail the 
  85. points I touch on below.
  86.  
  87. Here are some points to note about Y'CrCb. 
  88. Most of these are subtle points that can be ignored in one's first pass at attempting 
  89. to get things to work. Once things work acceptably, one may want to return to these
  90. points to ensure that onscreen display is not merely acceptable but as good as 
  91. possible.
  92.  
  93. • WHAT ABOUT GAMMA CORRECTION?
  94. The Y' component is gamma corrected. This will affect how and where you place 
  95. gamma correction in your card design, and if your card is designed for both PCs 
  96. and Macs you may want to have it toggle between two different modes to get the 
  97. gamma correction correct on both systems.
  98.  
  99. • WHAT ABOUT DIGITAL VIDEO PINNING?
  100. Y' has a nominal range of 16 through 235. 16 and values below are pure black, 235 and 
  101. values above are pure white. Values in between increase linearly in brightness. 
  102. The colorspace conversion may choose to ignore this nicety and simply map 0 to black, 
  103. 235 to white, in the usual fashion. However this can lead to regions of black looking 
  104. noticably noisy because random values between 01 and 16 that appear in those regions,
  105. and that are all supposed to map to black, instead map to noticably different blacks.
  106. Likewise the chroma components have nominal values between 16 and 240, however 
  107. ignoring those is pretty harmless in terms of visual damage.
  108.  
  109. • WHAT ABOUT ALTERNATIVE COLOR SAMPLING, EG 4:4:4?
  110. Right now we only deal with MPEG-1 and thus we only deal with 4:2:0 format (ie 
  111. chroma is subsampled by 2 in both the horizontal and vertical directions). At some point
  112. we'll add support for MPEG2 at which point we'll have to deal with other chroma 
  113. subsampling formats like 4:2:2 and 4:4:4. This will be handled by defining additional
  114. codec types for those formats (though presumably your code for building those codecs 
  115. will share the same code base as your code for this 4:2:0 codec).
  116.  
  117. • WHAT ABOUT SCALING?
  118. Your codec MUST deal with scaling. If it does not, it is essentially useless. Pretty 
  119. much all MPEG video is encoded with an aspect ration that is not 1, eg the video is 
  120. encoded at 352x240 samples but it is supposed to be displayed in a 320x240 window on 
  121. a monitor with square pixels. If your codec cannot cope with scaling, it will not be used
  122. and the software YCrCb codec will be used. 
  123. What is obviously optimal is if your card can do scaling in the card. If that is not 
  124. possible, what might be best is for your card to scale the data as it is reading it 
  125. in from the  YCrCbVideoFrame* data pointer and writing it out to your card's buffers.
  126. In addition it is not ideal to hardcode scaling at one value, say 352x240 scaled to 
  127. 320x240. That is the scaling that is used for NTSC video, but footage derived from
  128. PAL video will use different scaling again. Footage from film, or generated by computer
  129. might use different scaling again.
  130.  
  131. While scaling is pretty much non-negotiable, your codec has the option of not bothering 
  132. with clipping, or with some bit depths. Just as with any other codec, if you cannot deal 
  133. with clipping, or with a 4-bit screen depth or whatever, you simply make this known in 
  134. your PreDecompress() call and ICM will cover for you. Unlike scaling, clipping and 
  135. screen depths other than those you are built to support (presumably 24bit, 16bit and 
  136. maybe 8bit color or 8bit grey) are not common cases.
  137.  
  138. • WHAT ABOUT SOURCE EXTRACTION?
  139. Consider a source image (compressed as YCrCb) that one wishes to display. 
  140. QuickTime has always had a facility for specifying a source rectangle within that source
  141. image that is smaller than the entire image. 
  142. Now practically every MPEG stream has visual gunk of one sort or another around the edges,
  143. two or three pixels worth.
  144. The MPEG system allows the user to specify a "masking out" of that visual junk by 
  145. defining a source rectangle from the images that omits this junk.
  146. What this means for you is that your hardware/codec must be able to handle source 
  147. extraction. If you simply ignore it and rely on ICM to do the work for you, as with 
  148. scaling, you will be useless for practically all MPEG playback.
  149.  
  150. • WHAT ABOUT GREY-SCALE INPUT?
  151. The YCrCb input is almost always "24bit" input in the sense that the Y, cR and cB 
  152. values are 8bit values. However that input may also be, in a sense, 8-bit grey input 
  153. if some preference has been set asking the MPEG decoder not to decode color. 
  154. In this case image description describing the input data will still say that the
  155. data is 24bit, but the cbOffset, crOffset, and chromaRowBytes fields of the 
  156. YCrCbVideoFrame will be set to 0. 
  157.  
  158. Note that this is a property of the input format and is orthogonal to the screen display
  159. format. You may have color input (valid Y', cR and cB data) coming in for display to an
  160. 8-bit grey screen (although in that case you would simply ignore the chroma data 
  161. and display only Y'). Alternatively you could have grey scale data coming in 
  162. (Y valid but chroma offsets and rowBytes set to 0) for display on a color 16bit screen.
  163. (This latter case might occur if the user has decided they want smoother motion at 
  164. the expense of color and so tell the MPEG decode engine not to bother decoding color.)
  165.  
  166. • WHAT ARE THE DETAILS OF THE COLOR-CONVERSION MATRICES?
  167. The color conversion matrix used is 
  168.     R'=Y^             + 1.40200*Cr^
  169.     G'=Y^- 0.34414*Cb^- 0.71414*Cr^
  170.     B'=Y^+ 1.77200*Cb^
  171.  
  172.     where Cr^ = scale(Cr-128) ie the value from the cR array (which is in the range 
  173.     0, 255) with 128 subtracted from it and scaled to the [16, 240] range, 
  174.     ie Cr^= [256/(240-16)]*(cr-128).
  175.     likewise Cb^=[256/(240-16)]*(cr-128).
  176.     Y^=[256/(235-16)](Y'-16).
  177.  
  178.  
  179. An alternative formulation, with the scaling directly in the matrix is
  180.     R'=1.16(Y'-16)                  + 1.594 (cr-128)
  181.     G'=1.16(Y'-16) - 0.392 (cb-128) - 0.813 (cb-128)
  182.     B'=1.16(Y'-16) + 2.017 (cb-128)
  183.     
  184.  
  185. If you read different books you will see slightly different versions of the above.
  186. Quite how accurate one wishes to be depends on the CPU or transistor budget one throws
  187. at the problem. Details of exactly how the scaling is done are reasonably flexible
  188. within limits -- as long as the clamping of black Y' at 16 is respected one can ignore
  189. a few of the finicky details of the above if ignoring is convenient.
  190. One is welcome to use hardware/software that is designed for JPEG (which uses slightly
  191. different matrices) and the result may be acceptable to some users---but not to others.
  192.  
  193.